Subject: PU and LU NAmes in ACTLU/ACTPU

From: "Jim Fletcher ((919) 254-5929)" <[email-masked]>
Date: Tue, 5 Dec 95 15:16:52 EST

Ref:  Multiple notes on subject

> OK -- so I flunked English --- let me fix this ...

In response to all of the comments about IBM being afraid to change, as
the person who has dealt with numerous customers who have been less than
happy with IBM because we make a change that breaks NON COMFORMANT products,
> yes, I do NOT want to make the change. When VTAM ships a new
function, and old
stuff breaks, it is assumed to be VTAMs fault. When VTAM IS RIGHT, yet
the customer has 10,000 of the "defective" product installed, guess which
product gets to design and implement a change --- easy answer -- VTAM.

And yes, we could add a new knob to SYSDEF to say "send the info", but
we are trying to reduce SYSDEF, not increase it.

SO what I would suggest, if you feel that customers want the info,
is a DLUR option that says "send/nosend" since the
info IS provided to the DLUR. Thoughts?

---

From: "jim (j.) cobban" <[email-masked]>
Date: Wed, 6 Dec 1995 10:17:00 -0500

>info IS provided to the DLUR. Thoughts?

I am afraid that, even with the introduction of the 3746, it will be a long
time before even 50% of dependent LUs are attached through DLUR.

I appreciate your concern.  Certainly our own SNA customers cringe at the
amount of sysdef there is for an SNA network.  However, as I pointed out IBM
added the PU Capabilities vector on the ACTPU without considering the
possible existence of broken PU 2.0 implementations and without adding a
sysdef knob.   In my opinion the value of that vector (to signal VTAM
support for PSID) is significantly less than the value of being able to
synchronize network management info between VTAM and an attached box by
using common names.

However, as I noted in my proposal, it is only DLUR over which the AIW has
any jurisdiction, since the NCP BF is clearly part of the IBM proprietary
portion of SNA.  So in any agreement that we come to at most we can only
make a polite suggestion for IBM to consider this capability for the NCP BF.
IBM would have to evaluate it in terms of their customer requirements.  If
IBM, as a member of the AIW, would prefer that even that polite suggestion
be omitted from any proposal we agree to, then I can hardly see how the rest
of us could insist.  Ultimately the marketplace must decide which optional
features of a standard we each deliver.

On a more detailed level I would suggest that the ability to leave the
network name vectors in the ACTLU and ACTPU should be optional in DLUR, and
that furthermore whether or not the option is controlled by a configuration
knob should be an implementation decision.